Inside Macintosh: Programming With JManager /

Chapter 1 - Using JManager / Creating a Java Runtime Environment

Creating a Java Runtime Session

On the Mac OS platform, the Java runtime session is defined by the JMSessionRef object. To instantiate this object, you must call the function JMOpenSession (page 56). Listing 1-1 gives an example of creating a session.

Listing 1-1 Creating a session

static JMSessionRef theSession;

static Boolean initializeMRJ()
{
   JMSecurityOptions securityOptions = {
      kJMVersion,          /* the current version */
      eCheckRemoteCode,    /* code verifier option */

      false,               /* use http proxy? */
      { 0 },               /* proxy server name here */
      0,                   /* proxy server port here */

      false,               /* use ftp proxy? */
      { 0 },               /* ftp server name here */
      0,                   /* ftp server port here */
      
      false,               /* use a firewall proxy? */
      { 0 },               /* firewall server name here */
      0,                   /* firewall server port here */
      
      eAppletHostAccess,   /* applet network access option */
      eLocalAppletAccess,  /* applet access to local file system */
      true,                /* restrict class access */
      true                 /* restrict class definitions */
   };
   
   JMSessionCallbacks sessionCallbacks = {
      kJMVersion,          /* the current version */
      MyStandardOutput,    /* designated standard output */
      MyStandardError,     /* designated standard error */
      MyStandardIn         /* designated standard input */
   };
   
   return JMOpenSession(&theSession, &securityOptions,
                      &sessionCallbacks, 0) == noErr;
}

The instantiated JMSessionRef object is referenced by the value of theSession. Other JManager functions require you to pass this value to identify the session. (You can create more than one instantiation of the Java runtime environment if you desire.) The JMOpenSession function also requires you to pass two data structures. Both of these structures contain a field indicating the version of JManager you are using in your program. You should always set this value to kJMVersion. Setting this value prevents your program from accessing older (possibly incompatible) JManager functions.

Security Options

The JMSecurityOptions data structure indicates the desired security levels for the session as follows:

• The code verifier field specifies whether you want the code verifier to check the Java code before attempting to execute it. The code verifier analyzes the code to make sure that it is valid Java code and that it does not attempt any illegal or questionable actions (such as pointer arithmetic) that could give the code access to the Mac OS runtime environment. Typically you should use the code verifier if you plan to receive Java code from an untrustworthy source (such as over a network). See "Security Level Indicators" (page 41) for the available options.
• You can select proxy servers that act as gateways when you access data over a network. For example, if your company has a security firewall, all requests for code or data external to the company network must pass through the firewall before reaching the desired server. You can designate proxy servers for HTTP access, FTP access, and firewall access.
• The applet network access field designates the level of network access an applet can have. Typically you should set this to eAppletHostAccess to indicate that an applet can access only its host server. See "Security Level Indicators" (page 41) for a list of available options.
• The applet local file system access field designates whether an applet can access files stored on the host computer. Typically you should set this to eLocalAppletAccess to indicate that only an applet stored locally can access the local file system. See "Security Level Indicators" (page 41) for a list of available options.
• You can designate two flags, fRestrictClassAccess and fRestrictClassDefine, that indicate whether to allow class access or class definitions outside the java.* classes.

For more information about the security options structure, see "Session Security Options Structure" (page 45).

If you want to determine the current security levels for a particular session, you can use the JMGetSecurityOptions function (page 58). To change existing security levels, you can use the JMSetSecurityOptions function (page 58). You can also view or change security levels using the JMShowPropsDialog function (page 95). This function brings up a dialog box with a complete list of security options, which you can view or edit as desired.

Callbacks

The second structure you must pass to the JMOpenSession function is a set of callback functions to handle standard output, standard error, and standard input. For example, you could specify a function that would receive and parse text sent to the standard output. Since the Mac OS runtime environment does not have a command line, these callbacks are often unused and set to nil. (By default, any text sent to standard output or standard error is redirected to a file.) For information about the form of these functions, see MyStandardOutput (page 97), MyStandardError (page 98), and MyStandardIn (page 98).

For more information about the session callback structure, see "Session Callbacks Structure" (page 44).